Componentized Junction Models

ABSTRACT

A plurality of road junction configurations are defined with a different set of road segment models corresponding to each of the plurality of road junction configurations. One of the plurality of road junction configurations are selected for a route through a physical road junction. A model of the physical road junction is generated by assembling the set of road segment models corresponding to the selected road junction configuration. The three-dimensional model of the physical road junction is rendered.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation under 37 C.F.R. § 1.53(b) and 35U.S.C. § 120 of U.S. patent application Ser. No. 14/990,301, filed Jan.7, 2016, which is hereby incorporated by reference in its entirety.

FIELD

The following disclosure relates to turn-by-turn navigationapplications, and more particularly to providing turn-by-turn navigationfor road junctions.

BACKGROUND

Map data and other geographic data are used by computer based systems toprovide useful features to users. For example, computer based systemsmay identify routes to destinations or other points of interest. Anavigation system may determine the optimum route to be taken by the enduser to travel from an origin to a destination location from map datastored in a map database. Similarly, the navigation system may query themap data for nearby points of interest, or provide other map-relatedfunctions. The navigation system may provide a map view images andinstructions to the user based on the queried map database and map data.The images may include road intersections or junctions. However, theintersections or junctions provided by the navigation system may notaccurately match real world intersections or junctions.

SUMMARY

In one embodiment, a method is provided for componentized junctionmodels. A plurality of road junction configurations are defined with adifferent set of road segment models corresponding to each of theplurality of road junction configurations. One of the plurality of roadjunction configurations are selected for a route through a physical roadjunction. A model of the physical road junction is generated byassembling the set of road segment models corresponding to the selectedroad junction configuration. The three-dimensional model of the physicalroad junction is rendered.

In another embodiment, an apparatus for componentized junction models isprovided including at least one processor and at least one memoryincluding computer program code for one or more programs. The memory andcomputer program code is configured to, with the at least one processor,cause the apparatus to receive a plurality of road junctionconfigurations. Each of the plurality of road junction configurationscorrespond to a set of road segment models. The memory and computerprogram code is further configured to select one of the plurality ofroad junction configurations for a route through a physical roadjunction, to generate a three-dimensional model of the physical roadjunction using the corresponding set of road segment models of theselected road junction configuration and to render the three-dimensionalmodel of the physical road junction.

In another embodiment, a non-transitory computer readable mediumincluding instructions for componentized junction models that whenexecuted are operable to receive a plurality of characteristics of aroad junction, to select a set of road segment models corresponding tothe characteristics of the road junction, to generate a model of theroad junction by assembling the set of road segment models and to renderthe three-dimensional model of the physical road junction.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present invention are described herein withreference to the following drawings.

FIG. 1 illustrates an example map developer system according to anembodiment.

FIG. 2 illustrates an example of two road junction types.

FIG. 3 illustrates an example of a single decision point situationincluding a cloverleaf-style destination link.

FIGS. 4-5 illustrate an example of a set of supported road junctionarchetypes according to an embodiment.

FIG. 6 illustrates an originating link with three lanes connecting to astraight destination link with two lanes and an exit destination linkwith one lane.

FIG. 7 illustrates an originating link with three lanes connecting to astraight destination link with two lanes and an exit destination link oftwo lanes.

FIG. 8 illustrates an originating link with two lanes connecting to astraight destination link with two lanes and an exit destination link ofone lane.

FIG. 9 illustrates an originating link with three lanes connecting to astraight destination link with two lanes and an exit destination link oftwo lanes.

FIGS. 10A-10D illustrate examples of component models for modeling aphysical road junction according to an embodiment.

FIG. 11 illustrates an example of driving path splines.

FIG. 12 illustrates an example of driving guidance using driving pathsplines.

FIG. 13 illustrates a flowchart diagram of an embodiment of a method forconstructing a componentized junction model using a look-aside table.

FIGS. 14A-14B illustrate an example of a componentized junction modelaccording to an embodiment.

FIGS. 15A-15B illustrate another example of a componentized junctionmodel according to an embodiment.

FIGS. 16A-16B illustrate another example of a componentized junctionmode according to an embodiment.

FIGS. 17A-17B illustrate another example of a componentized junctionmode according to an embodiment.

FIGS. 18A-18B illustrate another example of a componentized junctionmode according to an embodiment.

FIGS. 19-20 illustrate another example of a set of supported roadjunction archetypes according to an embodiment.

FIGS. 21A-21B illustrate an example of generating physical road junctionmodels using componentized junction models with variable geometriesaccording to an embodiment.

FIG. 22 illustrates an example server device according to an embodiment.

FIG. 23 illustrates an example flowchart for the server device of FIG.20 according to an embodiment.

FIG. 24 illustrates an example mobile device according to an embodiment.

FIG. 25 illustrates an example flowchart for the mobile device of FIG.22 according to an embodiment.

DETAILED DESCRIPTION

Some current navigation systems use unique two-dimensional (2D) junctionview images or 2D renderings of three-dimensional (3D) junction modelsfor every junction in a map database (e.g., still images for each roadjunction). Storing unique junction view images or unique models for eachjunction is very space-intensive. Other navigation systems use a limitedset of generic 2D junction view images or 3D junction models toapproximate actual junction configurations. Using generic junction viewimages or generic models is space-efficient, but yields limited fidelitywith respect to the accuracy of junction topology, junction geometry,lane counts, and lane connectivity between road segments, and increasingfidelity requires a disproportionate increase in storage needs, oftenexponentially. There remains a need for navigation systems to be able todisplay junction view images for a very large variety of road junctionconfigurations with reasonable verisimilitude using a relatively smallamount of data in a storage-constrained system in order to provideguidance to users prior to performing driving maneuvers.

The following embodiments describe systems and methods for componentizedjunction models. A set of seamlessly interconnectable three-dimensional(3D) models of short road segments are provided that vary by shape andlane counts. The 3D models are assembled in various combinations tocreate a 3D model of an entire physical road junction. The completemodel of the physical road junction may be rendered and displayed as ajunction view image, using a static 2D rendering, a 3D animated view ofthe 3D model, or the like.

According to one or more embodiments, the interconnectable 3D componentmodels are predefined with each component segment representing a shortroad segment. For example, the 3D component models may be divided intothree general segment types or categories, such as: straight segments;curve segments; and fork segments (e.g., where one road segment splitsinto two or more road segments). The 3D component models also vary byshape and lane count within each segment type. For example, curvesegments may bend left or right, may bend sharply or gradually, and/ormay bend over a short or long distance. Further, curve segments mayrepresent an ascending or descending cloverleaf ramp. Additionally, lanecounts may vary within a single component model. For example, a straightcomponent model may provide two lanes that expand to four lanes.

A set of supported junction configurations is also defined. Eachjunction configuration corresponds to a predefined set of 3D componentmodels assembled in a specific way to generate a complete 3D model of aphysical junction. Physical, actual real world road junctions may bemapped by an algorithm to determine the closest fitting junctionconfiguration from the supported set of configurations. For any physicaljunction, the junction configuration that best fits the physicaljunction may vary depending on the route a navigation system chooses tonavigate through the physical road junction (e.g., accuracy along thedriven route is often a priority over accuracy of other parts of the 3Dmodel that represent non-driven routes).

The embodiments may allow for a navigation system to generate and rendera junction model, and display a road junction view in an extraordinarilyspace-efficient manner given the number of different approximatedjunction configurations supported by the navigation system. Further, thedesired average fidelity of the junction model approximations may beincreased or decreased by varying the number and type of componentmodels included or defined, allowing the navigation system to betailored to hardware limitations and the desired accuracy and fidelityof the end application. For example, in one embodiment, usingapproximately 2,500 component models, a navigation system may supportmore than 10²⁴ different junction configurations. Further, in anotherembodiment, using approximately 750 components, roughly 10²³ differentjunction configurations may be supported. In both instances, areasonable storage footprint is maintained on the navigation device.

FIG. 1 illustrates map developer system according to an embodiment. Thesystem 120 includes mobile devices 122 (e.g., navigation devices and/orassisted driving systems), a server 125 (e.g., a “cloud” server and/or amap developer system) and a network 127 (e.g., a cellular network). Thedatabases 123 a and 123 b may be map databases including road links,segments and junctions. Additional, different, or fewer components ofsystem 120 may be provided. For example, many varieties of mobiledevices 122 may connect with the network 127, including mobiletelephones, navigation systems, personal computers, assisted drivingvehicles, etc. Assisted driving vehicles include autonomous vehicles,highly assisted driving (HAD) and advanced driving assistance systems(ADAS). An assisted driving device 122 may be included in the vehicle.

In an embodiment, the server 125 or a mobile device 122 identifies aroad junction from the map database 123 a or 123 b, respectively. Themap databases 123 a and 123 b include generalized 3D model templates orconfigurations of road junctions, rather than 2D images for each roadjunction, in order to provide realistic lane counts, lane connectivity,and road shapes for the physical road junctions. The generalized 3Dmodel templates or configurations provide a complete specification ofall road segment components needed to assemble a complete 3D model of aroad junction and information on how to assemble the road segmentcomponents into the 3D model. The 3D model templates also includeoverpass and underpass road junction representation information. The mapdatabases also include a look-aside table (LAT) used to store andidentify each physical road junction that is supported. A 3D model willbe displayed using the road junction template that best matches thephysical road junction. In an example, map data for each physical roadjunction is added to the map database 123 a and/or 123 b (e.g., a coremap) and is used to determine which model template best fits thephysical road junction (e.g, using an algorithm). Junction inclusionrules may be performed to identify which physical road junctions thatwill be associated with 3D model templates. For example, off-ramps andhighway-to-highway connectors may be included, while T-shaped orfour-way intersections and roundabouts may be excluded. However, inother examples, additional, different or fewer model templates may beprovided for other physical road junctions types.

FIG. 2 illustrates an example of two generalized road junction types. Inthis example, road junctions are generally one of two types: a singledecision point situation (SDPS); or a multiple decision point situation(MDPS). Additional, different or fewer generalized road junction typesmay be included, such as three-way, four-way and higher order decisionpoint situations. For example, implementations for two-way splits in aroadway can be expanded to other implementations to support three-way,four-way, and higher order roadway splits. As depicted in FIG. 2, eachdecision point situation includes an originating link that is the roadsegment immediately preceding a divergence, referred to as a decisionpoint. Each decision point situation includes destination links that arethe road segments following a decision point. For example, singledecision point situations (SDPS) include an originating link thatdivides into one or more destination links. FIG. 2 depicts a SDPS withan originating link dividing into exactly two destination links.Multiple decision point situations (MDPS) include an originating linkthat divides into one or more links, including a destination link and anintermediate link. Intermediate links provide a continuous path betweentwo decision points and are not considered destination links. Forexample, after a first decision point (DP1), an intermediate link leadsto a second decision point (DP2). An intermediate link then divides intoone or more destination links. One or more intermediate lanes may divideDP1 from DP2. In an example, the second decision point occurs within alimited distance from the first decision point (e.g., 250 meters). FIG.2 also depicts a multiple decision point situation (MDPS) dividing intoexactly two links: a destination link and an intermediate link. Theintermediate link then divides again into exactly two more destinationlinks.

FIG. 3 illustrates an example of a single decision point situationincluding a cloverleaf-style destination link. Road junctions thatinclude cloverleaf-style overpasses or underpasses along the driven pathmay receive special treatment, as discussed below. A 3D model for a roadjunction includes an overpass or underpass if a destination link orintermediate link circles back and crosses over the path of theoriginating link at a different grade within a set distance (e.g.,ascending or descending). Additional overpasses and underpasses that maybe visible to a driver navigating a physical road junction may not bedisplayed.

FIGS. 4-5 illustrate an example of a set of supported road junctionarchetypes. For example, a right or left exit designates that after adecision point, one path continues in the same general direction set bythe originating link and another exit path veers off to the right orleft. A bifurcation designates that two paths diverge from theoriginating link such that no path continues in the same generaldirection set by the originating link (e.g., may be modeled as asymmetric “Y” shaped intersection that smoothly veers away from thegeneral direction set by the originating link). Each supported roadjunction may be coded using a syntax or other methodology foridentifying each type of road junction. For example, FIGS. 4-5 include asyntax for identifying various road junction archetypes for single andmultiple decision point situations. As depicted in FIGS. 4-5, each typeof decision point situation is described using the following syntax: “R”representing a right exit; “L” representing a left exit; “B”representing a bifurcation; “h” representing a horizontal fork or curve;“u” representing an ascending or upward curve; and “d” representing adescending or downward curve.

In addition to the road junction archetypes, the 3D model of a physicalroad junction may also include accurate lane counts and laneconnectivity for the junction. For example, for each physical roadjunction fitting an archetype, the number of lanes in the originatinglink, destination links, and intermediate links can vary. Modelingaccurate lane counts for originating and destination links may be simpleto implement because each originating or destination link is a singlelink connected to a single decision point. However, intermediate linksmay include multiple links between two decision points of a MDPSjunction, with each intermediate link having a different lane count andlane connections. For example, overpass and underpass junctions oftenhave different lane counts between intermediate links. Includingaccurate lane counts and connectivity for intermediate links mayincrease the complexity of the model, therefore intermediate links maybe represented in an abstract manner to simplify the design and limitcomplexity of junction models. Further, for junctions that do notinclude an overpass or underpass, the entire chain of intermediate linksmay be treated as a single intermediate link. In this example, the lanecount used for modeling a single representative intermediate link isdetermined by the intermediate link immediately preceding the seconddecision point.

For road junctions that include an overpass or underpass, treatingintermediate links as a single link may not be desirable because thenumber of lanes in a cloverleaf exit may be as important to a uservisually as the number of lanes in the overpass or underpass roadsegment (e.g., if the intermediate links lead to a second decisionpoint). For this reason, overpass and underpass junctions may be modeledaccurately with the correct number of lane counts for each road segment(e.g., with other intermediate segments abstracted). In this example,when a ramp lane count differs from an overpass or underpass lane count,a transition may be provided to join the cloverleaf ramp with theoverpass or underpass.

Accurate lane connectivity may also be modeled for a road junction. Fordifferent variations in lane counts for a given archetype, the lanes inthe originating link connect to the lanes in the destination links invarious ways. For example, lanes may connect directly, or may connect bysplitting, adding or removing lanes. For example, FIGS. 6-9 depictexamples of lane connectivity with segments of varying lane counts. FIG.6 depicts an originating link with three lanes connecting to a straightdestination link with two lanes and an exit destination link with onelane. As depicted in FIG. 6, every lane in the originating link connectsdirectly to a lane in one of the destination links. FIG. 7 depicts anoriginating link with three lanes connecting to a straight destinationlink with two lanes and an exit destination link of two lanes. Asdepicted in FIG. 7, the center lane of the originating link splits intotwo lanes, with one lane connecting to a lane of the straightdestination link and one lane connecting to the exit destination link.FIG. 8 depicts an originating link with two lanes connecting to astraight destination link with two lanes and an exit destination link ofone lane. As depicted in FIG. 8, a lane is added to the left lane of theoriginating link and connects to the two lanes of the straightdestination link. The right lane of the originating link connectsdirectly to the lane of the exit destination link. Lanes may be removedin the same manner. FIG. 9 depicts an originating link with three lanesconnecting to a straight destination link with two lanes and an exitdestination link of two lanes. As depicted in FIG. 9, the left lane isremoved from the originating link and the right two lanes connect to thetwo lanes of the straight destination link. The right lane of theoriginating link splits and connects to the left lane of the exitdestination link. A lane is added to the originating link and connectsto the right lane of the exit destination link.

In the examples provided above, the addition and removal of lanes is onemethodology to accurately model lane connectivity. As such, the laneadditions and removals may not exactly match the lane connectivityreality. However, adding and removing lanes in the model producesaccurate lane connectivity for visualizing a road junction. For example,in FIG. 8, the leftmost originating lane connects to both lanes in theleft destination link. This is modeled by adding a lane on the left sideof the originating link just before the split point. In FIG. 9, removinga lane on the left of the originating link and adding a lane on theright is modeled such that all three originating lanes continue straightand only the rightmost lane exits to the right. In these examples, theaccuracy of the modeled connectivity is more important than accuratelane counts.

Given the number of possible lane and connectivity variations for theroad junction archetypes, a syntax or naming convention for constructingthe 3D model may be used. For example, to construct single decisionpoint situations, the following naming convention may be used: A BCDEFGH Z; where A represents the junction configuration, BCD representsthe originating link lane counts, EFGH represents the destination linklane counts, and Z represents the conditional overpass or underpass lanecount. Using this example naming convention, the following rules may beapplied to model a physical road junction. For example, A is the type ofdecision point, with “R” for right exit, “L” for left exit, or “B” forbifurcation at the decision point. B is the number of originating lanesleading to the decision point. For a right or left exit (e.g., if A is“R” or “L”), C is the number of originating lanes leading to thestraight-on path, D is number of originating lanes leading to the exitpath, E is type of the straight-on destination path, with “h” for anormal horizontal road (e.g., cloverleaf ramps may not be allowed), F isnumber of destination lanes in the straight-on destination path, G isthe type of the exiting destination path, with “h” for a normalhorizontal road, “u” for ascending (up) cloverleaf ramp, and “d” fordescending (down) cloverleaf ramp, and H is number of destination lanesin the exiting path. For a bifurcation (e.g., if A is “B”), C is thenumber of originating lanes leading to the left path, D is the number oforiginating lanes leading to the right path, E is the type of the leftdestination path, with “h” for a normal horizontal road, “u” forascending (up) cloverleaf ramp, and “d” for descending (down) cloverleaframp, F is the number of destination lanes in the left path, G is thetype of the right destination path, with “h” for a normal horizontalroad, “u” for ascending (up) cloverleaf ramp, and “d” for descending(down) cloverleaf ramp, H is the number of destination lanes in theright path, and Z is the number of overpass or underpass lanes (e.g.,only present if E or G is “u” or “d”) allowing the lane count of theroad crossing over or under to differ from the lane count of thecloverleaf ramp destination path. The archetypes in FIG. 4 are labeledAEG.

To construct multiple decision point situations, the following namingconvention may be used: A BCD EFGH J K LMN PQRS Z. A represents thejunction configuration, BCD represents the originating link lane counts,EFGH represents the first destination and intermediate link(s) lanecounts, J represents the side of the second decision point, K representsthe second decision point junction configuration, LMN representintermediate link lane counts, PQRS represent the second decision pointdestination link lane counts, and Z represents the conditional overpassor underpass lane count. Using this example naming convention, thefollowing rules may be applied to model a physical road junction. Forexample, A is the type of the first decision point, with “R” for rightexit, “L” for left exit, or “B” for bifurcation at the first decisionpoint. B is the number of originating lanes leading to the firstdecision point. For a right or left exit (e.g., if A is “R” or “L”), Cis the number of originating lanes leading to the straight-on path ofthe first decision point, D is number of originating lanes leading tothe exit path of the first decision point, E is type of the straight-ondestination path, with “h” for a normal horizontal road (e.g.,cloverleaf ramps may not be allowed), F is number of destination lanesin the straight-on destination path of the first decision point, G isthe type of the exiting destination path of the first decision point,with “h” for a normal horizontal road, “u” for ascending (up) cloverleaframp, and “d” for descending (down) cloverleaf ramp, and H is number ofdestination lanes in the exiting path of the first decision point. For abifurcation (e.g., if A is “B”), C is the number of originating lanesleading to the left path of the first decision point, D is the number oforiginating lanes leading to the right path of the first decision point,E is the type of the left destination path of the first decision point,with “h” for a normal horizontal road, “u” for ascending (up) cloverleaframp, and “d” for descending (down) cloverleaf ramp, F is the number ofdestination lanes in the left path of the first decision point, G is thetype of the right destination path of the first decision point, with “h”for a normal horizontal road, “u” for ascending (up) cloverleaf ramp,and “d” for descending (down) cloverleaf ramp, and H is the number ofdestination lanes in the right path of the first decision point.

For the second decision point, J identifies whether the second decisionpoint is reach from the right or left branch (e.g., “R” for right and“L” for left), K is the type of the second decision point, with “R” forright exit, “L” for left exit, or “B” for bifurcation at the seconddecision point, L is the number of intermediate lanes leading to thesecond decision point. For a right or left exit (e.g., if K is “R” or“L”), M is the number of intermediate lanes leading to the straight-onpath of the second decision point, N is number of intermediate lanesleading to the exit path of the second decision point, P is type of thestraight-on destination path, with “h” for a normal horizontal road(e.g., cloverleaf ramps may not be allowed), Q is number of destinationlanes in the straight-on destination path of the second decision point,R is the type of the exiting destination path of the second decisionpoint, with “h” for a normal horizontal road, “u” for ascending (up)cloverleaf ramp, and “d” for descending (down) cloverleaf ramp, and S isnumber of destination lanes in the exiting path of the second decisionpoint. For a bifurcation (e.g., if K is “B”), M is the number oforiginating lanes leading to the left path of the second decision point,N is the number of originating lanes leading to the right path of thesecond decision point, P is the type of the left destination path of thesecond decision point, with “h” for a normal horizontal road, “u” forascending (up) cloverleaf ramp, and “d” for descending (down) cloverleaframp, Q is the number of destination lanes in the left path of thesecond decision point, R is the type of the right destination path ofthe second decision point, with “h” for a normal horizontal road, “u”for ascending (up) cloverleaf ramp, and “d” for descending (down)cloverleaf ramp, and S is the number of destination lanes in the rightpath of the second decision point. Z is the number of overpass orunderpass lanes (e.g., only present if E or G is “u” or “d”) when theoverpass or underpass does not lead to the second decision point,allowing the lane count of the road crossing over or under to differfrom the lane count of the cloverleaf ramp destination path. Forexample, the following combinations may be permissible: if A is “B”, Eis “u” or “d”, and J is “R”, then the left branch is a cloverleaf rampand the right branch leads to the second decision point; if A is “L”, Gis “u” or “d”, and J is “R”, then the left branch is a cloverleaf rampand the right branch leads to second decision point; and if A is “R” or“B”, G is “u” or “d”, and J is “L”, then the right branch is acloverleaf ramp and the left branch leads to second decision point.Additional, different or fewer combinations may be provided. Based onnaming scheme discussed above, the archetype for a MDPS junction asshown in FIG. 5 is defined by AEGJKPR. This naming scheme is provided asan exemplary embodiment of componentized junction templates. Othernaming conventions may be employed. Further, additional namingconvention examples are provided below and in the figures that combinetemplate names and with other concepts disclosed herein.

In the example naming convention provided above, lane count limits maybe provided. For example, setting limits on the number of lanesrepresented for the originating, destination and intermediate links maylimit the total number templates required, simplifying theimplementation, but may result in less accurate junction models. In animplementation, the following lane count limits may be provided:originating links may be one to eight lanes; straight-on destination orintermediate link lanes may be one to eight lanes; exiting destinationor intermediate link lanes (e.g., non-cloverleaf ramps) may be one toeight lanes; exiting destination or intermediate link lanes (e.g.,cloverleaf ramps) may be one to two lanes; destination link lanes aftera bifurcation may be one to eight lanes; and overpass or underpass lanesmay be one to eight lanes. Further, adding and removing lanes may belimited, such as a maximum of two originating or intermediate link lanesmay be removed at a decision point along one path through that decisionpoint and a maximum of four destination or intermediate link lanes maybe added at decision point along one path through that decision point.Additional, different or fewer lane count limits may be provided.

Using the naming convention discussed above, accurate three-dimensionalmodels of physical road junctions are constructed using component modelsof short road segments that vary by shape and lane counts. The componentmodels are selected using the naming convention described above, and areconnected together to model the physical road junction. In this example,the junction template name indicates a specific set of component modelsthat are used to generate the road junction model. Using the syntaxdiscussed above, three categories of component models are used: straightcomponents; fork components; and curve components. Straight componentsmodel a straight segment of road with a specified lane count, and mayhave lanes added or removed on either side. Fork components model a pathdivergence (e.g., either a left exit, right exit, or bifurcation) with aspecified lane count. In this example, lanes are not added or removedfrom a fork component, but lanes may split and follow one or more pathsof a fork component. Curve components model a curved segment of roadwith a specified lane count. In this example, lanes are not added orremoved from a curve component.

FIGS. 10A-10D depict examples of component models for modeling aphysical road junction. Another syntax or naming convention may be usedfor identifying the component models. For example, straight componentmodels may adhere to the following convention: SXYZ. As depicted in FIG.10A, “S” indicates a straight component, “X” represents number of lanesat the near end (in the driving direction) of the component model, “Y”represents the change in number of lanes on the left side between thenear and far ends of the component model (e.g., positive when addinglanes and negative when removing lanes), and “Z” represents the changein number of lanes on the right side between the near and far ends ofthe component model (e.g., positive when adding lanes and negative whenremoving lanes). Further, curve component models may adhere to thefollowing convention: CXYZ. As depicted in FIG. 10B, “C” indicates acurved component, “X” represents direction of the curve (e.g., “L” for acurve that bends left and “R” for a curve that bends right), “Y”represents the curve type (e.g., “h” for a normal horizontal curve, “u”for an ascending (up) cloverleaf ramp and “d” for a descending (down)cloverleaf ramp), and “Z” represents the lane count for the curve.Finally, for component models may adhere to the following convention:FAB.CD. As depicted in FIG. 10C, “F” indicates a fork component, “A”represents the fork direction (“R” for a right exit, “L” for a left exitor “B” for a bifurcation), and “B” represents the lane count at the nearend of the component (e.g., may be a one-digit or two-digit number,hence the need for the period between “B” and “C”). If “A” is “R” or“L”, then “C” represents the destination lane count on the straight pathand “D” represents the destination lane count on the exit path. If “A”is “B”, then “C” represents the destination lane count in the left pathand “D” represents the destination lane count in the right path. Variouscomponent models connect together by mating their accessors. FIG. 10Ddepicts an example of the accessors for each type of component, alongwith an example naming convention (e.g., “Start,” “Left End,” etc.). Forexample, an accessor of n lanes in a given component model connectsseamlessly to an n lane accessor of any other model.

Component models may also include driving path splines. As depicted inFIG. 11, driving path splines run down the center of each lane and areused to define a path of travel through the road junction model (e.g.,for each lane-level path). For example, driving path splines are used todefine a path for lane change maneuvers in straight component modelswhere lanes are added and/or removed. Lane change splines may also beused to trace paths for guidance arrows in MDPS junctions. For example,in FIG. 12, lane change splines are used for guidance through a seconddecision point (DP2) that follows a cloverleaf ramp. In someimplementations, lane change guidance is only provided throughcloverleaf ramps.

In another implementation, junction templates may include lane changeguidance before reaching a road junction. For example, lane changeguidance may be provided using a straight segment of a constant lanewidth (e.g., S100, S200, . . . , S800) placed before the first segmentof the road junction. In this implementation, the straight road segmentwill have splines showing all possible lane changes and with metadatalabels associated with each spline. For example, FIG. 11 depicts lanechange splines for various component segments, with the splineinformation referenced by a metadata label. In some implementations,components used to provide lane change guidance and those assembled toform junction models may differ. For example, lane change models andjunction models may be generated separately and joined together and soas to appear as a single model. Lane change guidance models may begenerated separately with different characteristics.

As discussed above, each junction template identifies a set of componentmodels to be connected together in a particular way. Each componentmodel is provided with a different label (e.g., according to a namingconvention). In an implementation, each junction template is provided arow in a look-aside table (LAT) and the corresponding component labelsfor each junction template are included in columns of a look-aside table(e.g., containing the specific component model names for the junctiontemplate). Further, a different junction template may be specified foreach route through a given junction archetype. Alternatively, onejunction template may be used for all routes through a junctionarchetype. In this implementation, the look-aside table contains a setof rows for each different junction archetype. Each row represents oneroute through a junction archetype. For example, assuming only two-waysplits, a junction archetype with a single decision point situation hastwo rows in the look-aside table (e.g., one row for each route throughthe road junction). A junction archetype with a multiple decision pointsituation has three rows in the look-aside table (e.g., the seconddecision point of every multiple decision point junction may berepresented by a separate single decision point situation junction).Using a LAT is only one exemplary implementation, thus listing thecomponent models in LAT columns is not always necessary. For example,component models may be derived from the junction template name.

When a look-aside table is used, not all columns (e.g., component modelparts) are used in every junction. When component model part is unused,the column will be left blank. Additionally, fillers may be used toextend the ends of components to fill up space to achieve a desiredmodel size. For example, fillers may be used to prevent small modelsfrom abruptly ending or to decrease the model size and complexity bydecreasing the number of components in each model. The filler counts maynot be derived from the template name. When a filler part name is blank,the corresponding count value will also be left blank. In thisimplementation, the following columns are included in the look-asidetable for each route:

DP_NODE_ID First decision point's Node ID. ORIGINATING_LINK_ID OriginLink ID (PVID) - link immediately prior to and entering the firstdecision point. DEST_LINK_ID Destination link ID (PVID) - linksimmediately following and exiting the decision point.JUNCTION_TEMPLATE_NAME Indicates the junction template to display forthis route through this decision point. SIDE Indicates whether thedestination link is leftmost (‘L’), rightmost (‘R’), or middle (‘M’)when viewed from the origin link on entering the first decision point.This also indicates which arrows in the junction model to display whentravelling from the origin link to the destination. LATITUDE Thelatitude of the first decision point. LONGITUDE The longitude of thefirst decision point. MDPS Indicates if given record is part of amultiple decision point (‘Y’/‘N’). ‘N’ for SDPS junctions. DP2_NODE_IDDecision point #2 node ID. DP1_INCOMING Component model used in thenamed position within the junction template. DP1_INCOMING_FILLERComponent model used in the named position within the junction template.DP1_INCOMING_FILLER_COUNT Number of DP1_INCOMING_FILLER parts toinclude. DP1_FORK Component model used in the named position within thejunction template. DP1_OUTGOING_1 Component model used in the namedposition within the junction template. DP1_OUTGOING_1_FILLER Componentmodel used in the named position within the junction template.DP1_OUTGOING_1_FILLER_COUNT Number of DP1_OUTGOING_1_FILLER parts toinclude. DP1_OUTGOING_2 Component model used in the named positionwithin the junction template. DP1_OUTGOING_2_FILLER Component model usedin the named position within the junction template.DP1_OUTGOING_2_FILLER_COUNT Number of DP1_OUTGOING_2_FILLER parts toinclude. DP1_MERGE Component model used in the named position within thejunction template. DP1_MERGE_INCOMING Component model used in the namedposition within the junction template. DP1_MERGE_INCOMING_FILLERComponent model used in the named position within the junction template.DP1_MERGE_INCOMING_FILLER_COUNT Number of DP1_MERGE_INCOMING_FILLERparts to include. DP1_MERGE_OUTGOING Component model used in the namedposition within the junction template. DP1_MERGE_OUTGOING_FILLERComponent model used in the named position within the junction template.DP1_MERGE_OUTGOING_FILLER_COUNT Number of DP1_MERGE_OUTGOING_FILLERparts to include. DP2_INCOMING Component model used in the namedposition within the junction template. DP2_FORK Component model used inthe named position within the junction template. DP2_OUTGOING_1Component model used in the named position within the junction template.DP2_OUTGOING_1_FILLER Component model used in the named position withinthe junction template. DP2_OUTGOING_1_FILLER_COUNT Number ofDP2_OUTGOING_1_FILLER parts to include. DP2_OUTGOING_2 Component modelused in the named position within the junction template.DP2_OUTGOING_2_FILLER Component model used in the named position withinthe junction template. DP2_OUTGOING_2_FILLER_COUNT Number ofDP2_OUTGOING_2_FILLER parts to include.

FIG. 13 illustrates a flowchart diagram of an embodiment of a method forconstructing a componentized junction model using a look-aside table.The method is implemented by the system of FIG. 1, 22 (discussed below),24 (discussed below) and/or a different system. Additional, different orfewer acts may be provided. The method is provided in the order shown.Other orders may be provided and/or acts may be repeated.

At act 101, a full or partial route through a physical road junction iscalculated or received by a navigation system. At act 103, a junctiontemplate for a route through the physical road junction is identified.The identified junction template corresponds with the physical roadjunction. For example, the junction template is located in a look-asidetable. The row located in the look-aside table includes a list ofcomponent models and other information used to generate athree-dimensional model of the physical road junction. At act 105, thejunction template is looked up in the look-aside table to accessinformation from the corresponding row (e.g., accessing a list ofcomponent models used to model the physical road junction). Thecomponent models are selected using construction rules that narrow downthe possible component models to specific component model names. At act107, a model of the physical road junction is generated by assemblingthe selected component models in the specific order provided by thelook-aside table.

For example, FIGS. 14-18 depict various examples of generating physicalroad junction models using componentized junction models. FIGS. 14A-14Bdepict a model of a junction named R321h2h1. FIGS. 15A-15B depict amodel of a junction named L322h3h2LB221h2h1. FIGS. 16A-16B depict amodel of a junction named R211h2u23. FIGS. 17A-17B depict a model of ajunction named R431h2u1RR322h3h1. FIGS. 18A-18B depict a model of ajunction named R431h2u1LR211h1h13. As depicted in FIGS. 14-18, thejunction template names, such as R321h2h1, completely and unambiguouslyidentify the component models that must be used to construct a complete3D junction model and how the component models all fit together togenerate a road junction model. In these examples, the road junctionshapes adhere to a set of pre-defined stylized patterns (e.g., using analgorithm or human judgment). Using the generalized component models,the road junction model may or may not realistically or closely matchthe shape of the physical road junction.

In other embodiments, a naming convention or other methodology forcategorizing physical road junctions does not specify the specificcomponent models to be used to construct the junction. In theseembodiments, the model is constructed using conditional logic. Forexample, FIGS. 19-20 illustrate another example of a set of supportedroad junction archetypes. In this example, the component models may bearranged in many positions defined by an existing junction template byusing variable component models of one of multiple different shapes(e.g., various exit angles, curve angles, etc.). There are nearly aninfinite number of ways each component model may vary, therefore thejunction model generated may more closely match the real world geometryof the physical road junction. Using a variable component models, acomplete junction definition specifies each variant at every position inthe road junction. For example, a naming convention as described abovemay be modified by adding additional information regarding the variablecomponent models. Additional information is appended to the end of theexisting junction template names. In this example, the naming conventionand junction modeling may be simplified by removing the distinction infork geometry to reflect a generalized and variable fork componentmodels (i.e., right exits, left exits and bifurcations may no longer bedistinguished). In this example, all forks are considered bifurcations,but by varying the shapes of the components used, junction models canstill represent right exits and left exits with even greater accuracy.

In this example, the naming convention for the component models includetwo additional variables for each path. For example, for each componentmodel, the naming convention includes a two digit angle variable. For acurved component model, a left curve is identified by “L”<turn angle>(e.g., “L15” is a left curve at 15 degrees) and a right curve isidentified by “R”<turn angle> (e.g., “R20” is a right curve at 20degrees). For each fork component model, the fork is identified by“F”<angle of left path>.<angle of right path> (e.g., “F0.25” is a rightexit at 25 degrees). In cases where a variable is unused, the variableis set to “_” (underscore) as a placeholder for the variable (e.g.,because the components of the naming convention are positional).Further, to more accurately model a road junction, extenders are used toaccurately model the path leading to and away from decision points. Forexample, one or more extenders are used to model a distance before andafter a decision point. For example, a threshold number of extenders(e.g., two extenders before and after each decision point) or athreshold distance (e.g., 250 meters before and after each decisionpoint) may be used.

Thus, a syntax or naming convention for constructing the 3D model of thephysical road junction may be used including the additional variablesfor the component models. For example, to construct single decisionpoint situations, the following naming convention may be used: BCD EFGZ/d/efg/hij/stu/v/wxy; where BCD represents the originating link lanecounts, EFGH represents the destination link lane counts, Z representsthe conditional overpass/underpass lane count, d represents the firstdecision point fork type, efg represent the first decision pointdestination path type, hij represent the first decision pointdestination path type, stu represent the conditional first decisionpoint incoming path type, v represents the conditional first decisionpoint merge type, and wxy represents the conditional first decisionpoint destination merge type. Using this example of a junction namingconvention, following rules may be applied to model a physical roadjunction. For example, variables B, C, D, F, H, and Z remain unchangedas discussed above and variable A is no longer used. For road junctionsthat do not include an overpass or underpass, variables s, t, u, v, w,x, and y are omitted (e.g., may be represented as “_”). Variables E andG may support cloverleaf ramps that do not lead to merges. B is thenumber of originating lanes leading to the decision point, C is thenumber of originating lanes leading to the left path, and D is thenumber of originating lanes leading to the right path. E is the type ofthe left destination path, with “h” for a normal horizontal road, “u”for ascending (up) cloverleaf ramp that leads to a merge, “d” fordescending (down) cloverleaf ramp that leads to a merge, “U” forascending (up) cloverleaf ramp that does not lead to a merge, and “D”for descending (down) cloverleaf ramp that does not lead to a merge. Fis the number of destination lanes in the left path. G is the type ofthe right destination path, with “h” for a normal horizontal road, “u”for ascending (up) cloverleaf ramp that leads to a merge, “d” fordescending (down) cloverleaf ramp that leads to a merge, “U” forascending (up) cloverleaf ramp that does not lead to a merge, and “D”for descending (down) cloverleaf ramp that does not lead to a merge. His the number of destination lanes in the right path. Z is the number ofoverpass or underpass lanes (e.g., only present if E or G is “u” or “d”)allowing the lane count of the road crossing over or under to differfrom the lane count of the cloverleaf ramp destination path.

To define the specific shape of the junction model, d defines the forkangles of the decision point (e.g., “F”<angle of left path>.<angle ofright path>), e defines the destination link from the left path of thedecision point (e.g., straight or curved), f defines the first extenderfrom the destination link of the left path of the decision point (e.g.,straight or curved), and g defines the second extender from thedestination link of the left path of the decision point (e.g., straightor curved). Further, h defines the destination link from the right pathof the decision point (e.g., straight or curved), i defines the firstextender from the destination link of the right path of the decisionpoint (e.g., straight or curved), and j defines the second extender fromthe destination link of the right path of the decision point (e.g.,straight or curved). Additionally, s defines the originating link to themerge point (e.g., straight or curved), t defines the first extenderfrom the originating link to the merge point (e.g., straight or curved),and u defines the second extender from the originating link to the mergepoint (e.g., straight or curved). Finally, v defines the fork angles ofthe merge point (e.g., “F”<angle of left path>.<angle of right path>), wdefines the destination link from the merge point (e.g., straight orcurved), x defines the first extender from the destination link from themerge point (e.g., straight or curved), and y defines the secondextender from the destination link from the merge point (e.g., straightor curved).

To construct multiple decision point situations, the following namingconvention may be used: BCD EFGH J LMN PQRSZ/d/efg/hij/kl/mno/pqr/stu/v/wxy; where BCD represents the originatinglink lane counts, EFGH represents the first decision point destinationlink lane counts, J represents the side of the second decision point,LMN represent the intermediate link lane counts, PQRS represent thesecond decision point lane counts, Z represents the conditionaloverpass/underpass lane count, d represents the first decision pointfork type, efg represent the first decision point destination path type,hij represent the first decision point destination path type, klrepresent the second decision point incoming link and second decisionfork type, mno represent the second decision point destination pathtype, pqr represent the second decision point destination path type, sturepresent the conditional first decision point incoming path type, vrepresents the conditional first decision point merge type, and wxyrepresent the conditional first decision point destination merge type.Similarly, variables B, C, D, E, F, G, H, J, L, M, N, P, Q, R, S, and Zremain unchanged as discussed above and variable A and K are no longerused. For road junctions that do not include an overpass or underpass,variables s, t, u, v, w, x, and y are omitted (e.g., may be representedas “_”). Variables E and G may support cloverleaf ramps that do not leadto merges.

Further, to define the specific shape of the junction model, in additionto d/efg/hij/stu/v/wxy as discussed above, k defines the intermediatelink to the second decision point (e.g., straight or curve, and straightif the lane count is not constant), l defines the fork angles of thesecond decision point (e.g., “F”<angle of left path>.<angle of rightpath>), m defines the destination link from the left path of the seconddecision point (e.g., straight or curved), n defines the first extenderfrom the destination link of the second decision point (e.g., straightor curved), o defines the second extender from the destination link ofthe second decision point (e.g., straight or curved), p defines thedestination link from the right path of the second decision point (e.g.,straight or curved), q defines the first extender from the destinationlink of the right path of the decision point (e.g., straight or curved),and r defines the second extender from the destination link of the rightpath of the decision point (e.g., straight or curved).

In an embodiment, the incoming path to the first decision point maycontinue to be represented solely by straight components to simplifypre-maneuver lane change guidance and to simplify the transition betweenpre-maneuver guidance and the guidance provided through the roadjunction. Further, the components connecting to forks may also berepresented solely by straight components. In this example, restrictingthese component models to straight components may greatly limit thetotal number of component models necessary to accurately model aphysical road junction.

Thus, to generate a 3D model of the physical junction, component modelsare assembled. With variable component models (e.g., addition of degreesof freedom, such as variable angles and lane counts), the componentmodel naming convention from above is modified. For example, straightcomponent models are provided as discussed above, but more complexmodels may be generated using curve models that may add or remove lanesand turn at any angle, and fork models that are variable with respect tothe angle of each branch relative to the starting direction. Forexample, straight component models may adhere to the followingconvention: SXYZ; where “X” represents the number of lanes at the nearend (in the driving direction) of the component model, “Y” representsthe change in number of lanes on the left side between the near and farends of the component model (e.g., positive when adding lanes andnegative when removing lanes), and “Z” represents the change in numberof lanes on the right side between the near and far ends of thecomponent model (e.g., positive when adding lanes and negative whenremoving lanes). Further, curve component models may adhere to thefollowing convention: CUV.W.X; where “U” represents the direction thecurve bends (e.g., “L” if the curve bends toward the left or “R” if itbends toward the right), “V” represents the curve type (e.g., “h” for anormal horizontal road, “u” for ascending (up) cloverleaf ramp, or “d”for descending (down) cloverleaf ramp), “W” represents the turn angle(e.g., positive integral degrees in the direction of curvature definedby U; the angle between the normal vectors of the Start and Endaccessors), and “X” represents the number of lanes in the componentmodel. Finally, fork component models may adhere to the followingconvention: FA.B.C.DE; where “A” represents the angle of the left path(e.g., positive integral degrees, with positive being in the directionaway from the right path; the angle between the normal vectors of thestart and left end accessors), “B” represents the angle of the rightpath (e.g., positive integral degrees, with positive being in thedirection away from the left path; the angle between the normal vectorsof the start and right end accessors), “C” represents the number oflanes at the near end of the component model (e.g., may be a one- ortwo-digit number, hence the need for the period), “D” represents thenumber of destination lanes in the left path, and “E” represents thenumber of destination lanes in the right path.

In various embodiments, the lane counts may not vary when components areassembled (e.g., component models may inherit the lane count of frompart of the path closest to the nearest decision point). However, inother embodiments, lane counts may vary, and may result in a morecomplex junction template name and look-aside table. For example, in anembodiment, only the curve angle of a cloverleaf curve component modelmay vary. In this embodiment, the number of variations supported dependson the number and nature of the fork component variations (e.g.,assuming overpasses and underpasses always cross the originating pathperpendicularly). Further, to add more junction configurations, the roadmerging into a cloverleaf ramp on the approach to an overpass/underpassis now optional. This will require variations of cloverleaf ramps withmore angular rotation so they can reach all the way around to theoverpass/underpass path without first connecting to a Fork component atthe merge.

FIGS. 21A-21B depict an example of generating physical road junctionmodels using componentized junction models with variable geometries.FIGS. 21A-21B depict a model of a junction named:431h2u1R322h3h1/F0.25/R10SL10/R235_/SF0.40/R10SL30/SR20S/R15R45S/F10.0/S_.Using the variable component models, the road junction model mayrealistically and closely match the shape of the physical road junction.

FIG. 22 illustrates an example server device according to an embodiment.The server 125 includes a processor 300, a communication interface 305,and a memory 301. Additional, different, or fewer components may beprovided. The processor 300 may be any processor suitable for theexecution of a computer program include, by way of example, both generaland special purpose microprocessors, and one or more processors of anykind of digital computer. Generally, a processor receives instructionsand data from a read only memory, a random access memory or both. Theserver 125 may be coupled to a database 123 a and a workstation 310.Additional, different, or fewer components may be provided. Theworkstation 310 may be used by a user to access the server 125. Thedatabase 123 a may store map or other geographic data, and informationcollected by mobile devices 122 (e.g., vehicle and environmentalparameters).

FIG. 23 illustrates an example flowchart for the server device of FIG.22 according to an embodiment. Additional, different or fewer acts maybe provided. The method is provided in the order shown. Other orders maybe provided and acts may be repeated.

At act 201, the server 125 maps a plurality of physical road junctionand stores the map data in a memory 301 or a database 123 a. Forexample, the server 125 maps a physical road junction using analgorithm. Further, various routes through a physical road junction maybe mapped separately. Alternatively, the server 125 maps a physical roadjunction based on information received from mobile devices 122. Further,a map of one or more physical road junctions may be received fromanother location, such as a third party provider of map data.

At act 203, the server 125 defines a plurality of road junctionconfigurations and stores the configurations in a memory 301 or adatabase 123 a. For example, a different set of road segment modelscorrespond to and may be assembled for each of the plurality of roadjunction configurations. In an implementation, each of the plurality ofroad junction configurations defines either a single-decision junctionor a double-decision junction. Further, each of the plurality of roadjunction configurations includes one or more of curved road segmentmodels, fork road segment models and/or straight road segments. Each ofthe plurality of road segment models varies by shape, lane count orboth. For example, straight road segment models may vary by a lane countthat includes a first number of lanes entering the straight road segmentmodel and a second number of lanes exiting the straight road segmentmodel. Likewise, curved road segment models may vary by a curvedirection including a right curve or a left curve, by a curve typeincluding a horizontal curve, an ascending curve or a descending curve,and by a lane count. Further, fork road segment models may vary by afork type including a left exit, a right exit or a bifurcation, and by alane count including a first number of lanes entering the fork roadsegment model, a second number of lanes exiting the fork road segmentmodel to the left and a third number of lanes exiting the fork roadsegment to the right. In another embodiment, the component models mayalso vary by curve angle, fork angle and lane angle. Further, extendercomponent models may be provided leading to and leading away from othercomponent models, such as forks, exits and other components.

At act 205, server 125 selects one of the plurality of road junctionconfigurations for a route through the physical road junction. Forexample, a road junction configuration may be selected using thecharacteristics of the mapped physical road junction. At act 207, theserver 125 generates a model of the physical road junction by assemblingthe set of road segment models corresponding to the selected roadjunction configuration. The generated model of the road junction may bea three-dimensional or two-dimensional model. At act 209, the server 125renders the model of the physical road junction. For example, therendered model of the road junction may be a static two-dimensionalrendering or an animated three-dimensional rendering. At act 211, theserver 125 or a mobile device 122 displays the rendered model of theroad junction. For example, the model may be displayed along withdriving directions or other instructions for navigating the routethrough physical road junction.

FIG. 24 illustrates an example mobile device according to an embodiment.The mobile device 122 includes a processor 200, a memory 204, an inputdevice 203, a communication interface 205, position circuitry 207, and adisplay 211. Additional, different, or fewer components are possible forthe mobile device 122.

The processor 200 may be any processor suitable for the execution of acomputer program include, by way of example, both general and specialpurpose microprocessors, and anyone or more processors of any kind ofdigital computer. Generally, a processor receives instructions and datafrom a read only memory, a random access memory or both.

The positioning circuitry 207 may include a Global Positioning System(GPS), Global Navigation Satellite System (GLONASS), or a cellular orsimilar position sensor for providing location data. The positioningsystem may utilize GPS-type technology, a dead reckoning-type system,cellular location, or combinations of these or other systems. Thepositioning circuitry 207 may include suitable sensing devices thatmeasure the traveling distance, speed, direction, and so on, of themobile device 122. The positioning system may also include a receiverand correlation chip to obtain a GPS signal. Alternatively oradditionally, the one or more detectors or sensors may include anaccelerometer built or embedded into or within the interior of themobile device 122. The accelerometer is operable to detect, recognize,or measure the rate of change of translational and/or rotationalmovement of the mobile device 122. The mobile device 122 receiveslocation data from the positioning system. The location data indicatesthe location of the mobile device 122.

The input device 203 may be one or more buttons, keypad, keyboard,mouse, stylist pen, trackball, rocker switch, touch pad, voicerecognition circuit, or other device or component for inputting data tothe mobile device 100. The input device 203 and the display 211 may becombined as a touch screen, which may be capacitive or resistive. Thedisplay 211 may be a liquid crystal display (LCD) panel, light emittingdiode (LED) screen, thin film transistor screen, or another type ofdisplay.

The controller 200 and/or processor 200 may include a general processor,digital signal processor, an application specific integrated circuit(ASIC), field programmable gate array (FPGA), analog circuit, digitalcircuit, combinations thereof, or other now known or later developedprocessor. The controller 200 and/or processor 200 may be a singledevice or combinations of devices, such as associated with a network,distributed processing, or cloud computing.

The memory 204 and/or memory 301 may be a volatile memory or anon-volatile memory. The memory 204 and/or memory 301 may include one ormore of a read only memory (ROM), random access memory (RAM), a flashmemory, an electronic erasable program read only memory (EEPROM), orother type of memory. The memory 204 and/or memory 301 may be removablefrom the mobile device 122, such as a secure digital (SD) memory card.

The communication interface 205 and/or communication interface 305 mayinclude any operable connection. An operable connection may be one inwhich signals, physical communications, and/or logical communicationsmay be sent and/or received. An operable connection may include aphysical interface, an electrical interface, and/or a data interface.The communication interface 205 and/or communication interface 305provides for wireless and/or wired communications in any now known orlater developed format.

The mobile device 122 may be assisted driving vehicles. Assisted drivingvehicles include autonomous vehicles, highly assisted driving (HAD), andadvanced driving assistance systems (ADAS). Any of these assisteddriving systems may be incorporated into mobile device 122.Alternatively, an assisted driving device may be included in thevehicle. The assisted driving device may include memory, a processor,and systems to communicate with the mobile device 122.

The term autonomous vehicle may refer to a self-driving or driverlessmode in which no passengers are required to be on board to operate thevehicle. An autonomous vehicle may be referred to as a robot vehicle oran automated vehicle. The autonomous vehicle may include passengers, butno driver is necessary. These autonomous vehicles may park themselves ormove cargo between locations without a human operator. Autonomousvehicles may include multiple modes and transition between the modes.The autonomous vehicle may steer, brake, or accelerate the vehicle basedon the merge notification.

A highly assisted driving (HAD) vehicle may refer to a vehicle that doesnot completely replace the human operator. Instead, in a highly assisteddriving mode, the vehicle may perform some driving functions and thehuman operator may perform some driving functions. Vehicles may also bedriven in a manual mode in which the human operator exercises a degreeof control over the movement of the vehicle. The vehicles may alsoinclude a completely driverless mode. Other levels of automation arepossible. The HAD vehicle may control the vehicle through steering orbraking in response to the merge notification.

Similarly, ADAS vehicles include one or more partially automated systemsin which the vehicle alerts the driver. The features are designed toavoid collisions automatically. Features may include adaptive cruisecontrol, automate braking, or steering adjustments to keep the driver inthe correct lane. ADAS vehicles may issue controls for these feature inresponse to merge notification.

Driving assistance may be provided based on the junction model and anarray of sensors that may include any combination of a brake sensor, asteering sensor, an environment sensor, a vehicle sensor, an opticalsensor, and an inertial sensor. Additional, different, or fewer sensorsmay be used.

The brake sensor may be a brake pedal sensor that detects displacementof the brake pedal of the vehicle. The brake sensor may detect theactuation of the brake pads near the wheel of the vehicle. The brakesensor may be a circuit that detects operation of the brakes through ananti-lock brake system. The steering sensor may be a steering wheelsensor that detects movement of the steering wheel of the vehicle. Thesteering sensor may detect the angle of the steering wheel. The steeringsensor may detect the angle of the front wheel of the vehicle. Theenvironment sensor may detect the environment of the vehicle. Theenvironment sensor may include a weather sensor such as a thermometer,barometer, or a rain sensor. The rain sensor may detect the movement ofwindshield wipers. The vehicle sensor may detect an operation of thevehicle. The vehicle sensor may include a throttle sensor that measuresa position of a throttle of the engine or a position of an acceleratorpedal, a speedometer sensor, or a tachometer sensor. The vehicle sensormay detect a malfunction of the vehicle. For example, the vehicle sensormay be a tire pressure sensor. The optical sensor may include a camera,a LiDAR device, a proximity sensor, or another sensor configured todetect distances to nearby objects or when a nearby object exists. Theoptical sensor may send a signal that reflects off another object and isdetected by the optical sensor. The inertial sensor may include aninertial measurement unit (IMU) including one or more of anaccelerometer, a gyroscope, and a magnetic sensor. The inertial sensormay generate data indicative of the acceleration, deceleration,rotational acceleration, and rotation deceleration experienced by thevehicle.

FIG. 25 illustrates an example flowchart for the mobile device of FIG.24 according to an embodiment. Additional, different or fewer acts maybe provided. The method is provided in the order shown. Other orders maybe provided and steps may be repeated.

At act 301, the mobile device 122 receives a plurality ofcharacteristics of a road junction. At act 303, the mobile device 122selects a set of road segment models corresponding to thecharacteristics of the road junction along the desired route. Forexample, each of the each of road segment models varies by shape, lanecount or both. At act 305, the mobile device 122 generates athree-dimensional model of the road junction by assembling the set ofroad segment models. At act 307, the mobile device 122 renders thethree-dimensional model of the physical road junction. At act 309, themobile device 122 displays the rendered model of the road junction.

Referring back to FIG. 1, map databases, such as geographic databases123 a and 123 b, are used in computer-based systems that provide usefulfeatures to users. For example, map databases are used for theidentification of routes to destinations or points of interest. Anavigation system determines the optimum route to be taken by the enduser to travel from the origin to the destination location from map datastored in a geographic (or map) database. Map databases are also used inadvanced driver assistance systems, such as curve warning systems,adaptive cruise control systems and headlight aiming systems. Mapdatabases are also used in systems that improve vehicle fuel economy,such as systems that optimize transmission gear selection taking intoaccount upcoming slope and speed changes.

As shown in FIG. 1, a master copy of the geographic database 123 a maybe stored at the server 125, and a local copy of the geographic database123 b may be stored at the mobile device 122. In one example, the localcopy of the database 123 b is a full copy of the geographic database,and in another example, the local copy of the database 123 b may be acached or partial portion of the geographic database. The cached portionmay be defined based on a geographic location of the mobile device 122or a user selection made at the mobile device 122. The geographicdatabases 123 a and 123 b may be a geographic database including roadlinks or segments. Additional, different, or fewer components may beprovided.

The geographic databases 123 a and 123 b may store or maintaingeographic data such as, for example, road segment or link data recordsand node data records. The geographic databases 123 a and 123 b may alsostore or maintain one or more look-aside tables (LAT). The link datarecords are links or segments representing the roads, streets, or paths.The node data records are end points (e.g., intersections) correspondingto the respective links or segments of the road segment data records.The road link data records and the node data records may represent, forexample, road networks used by vehicles, cars, and/or other entities.

Each road segment may be associated with two nodes (e.g., one noderepresents the point at one end of the road segment and the other noderepresents the point at the other end of the road segment). The node ateither end of a road segment may correspond to a location at which theroad meets another road, i.e., an intersection, or where the roaddead-ends. Each road segment may be associated with zero or more shapepoints. Shape points are an ordered sequence of vertices that indicatethe shape of the road as a polyline between the nodes. The road shapemay also be represented by an analytical curve such as a B-spline,Bezier curve, Clothoid curve or other curve types. The road segments mayinclude sidewalks and crosswalks for travel by pedestrians.

Each of the road segments or links may be associated with variousattributes or features stored in lists that are not byte aligned. Theroad segment data record may include data that indicate a speed limit orspeed category (i.e., the maximum permitted vehicular speed of travel)on the represented road segment. The road segment data record may alsoinclude data that indicate a classification such as a rank of a roadsegment that may correspond to its functional class. The road segmentdata may include a segment ID by which the data record can be identifiedin the geographic database 123. The road segment data, nodes, segmentIDs, attributes, fields, and other data may be organized in datastructures described above.

The road segment data may include data identifying what turnrestrictions exist at each of the nodes which correspond tointersections at the ends of the road portion represented by the roadsegment, the name or names by which the represented road segment isknown, the length of the road segment, the grade of the road segment,the street address ranges along the represented road segment, thepermitted direction of vehicular travel on the represented road segment,whether the represented road segment is part of a controlled access road(such as an expressway), a ramp to a controlled access road, a bridge, atunnel, a toll road, a ferry, and so on. The additional road segmentdata may be organized in data tree structures. Alternatively, the datatree structures may be included in a separate database, for example,internal to the server 125 and/or the mobile device 122, or at anexternal location.

The server 125 may send map updates to the mobile device 122. The server125 may update a particular tile of the geographic database 123. Theserver 125 may send updates to the master copy of the geographicdatabase 123 a and/or send updates to the local copy of the geographicdatabase 123 b. The server 125 may generate an update script or patchfile for the navigation data and transmit the update script or patchfile to the mobile device 122 to update the local copy of the database123 b.

The mobile device 122 may be a personal navigation device (“PND”), aportable navigation device smart phone, a mobile phone, a personaldigital assistant (“PDA”), a tablet computer, a notebook computer,and/or any other known or later developed mobile device or personalcomputer. The mobile device 122 may also be an automobile head unit,infotainment system, and/or any other known or later developedautomotive navigation system. Non-limiting embodiments of navigationdevices may also include relational database service devices, mobilephone devices, car navigation devices, and navigation devices used forair or water travel.

The mobile device 122 may be configured to execute routing algorithms todetermine an optimum route to travel along a road network from an originlocation to a destination location in a geographic region. Using inputfrom the end user, the mobile device 122 examines potential routesbetween the origin location and the destination location to determinethe optimum route. The mobile device 122 may then provide the end userwith information about the optimum route in the form of guidance thatidentifies the maneuvers required to be taken by the end user to travelfrom the origin to the destination location. Some mobile devices showdetailed maps on displays outlining the route, the types of maneuvers tobe taken at various locations along the route, locations of certaintypes of features, and so on.

The computing resources may be divided between the server 125 and themobile device 122. In some embodiments, the server 125 performs amajority of the processing. In other embodiments, the mobile device 122performs a majority of the processing. In addition, the processing maybe divided substantially evenly between the server 125 and the mobiledevice 122.

The map developer system in server 125 and the mobile device 122 arecoupled with the network 127. The phrase “coupled with” is defined tomean directly connected to or indirectly connected through one or moreintermediate components. Such intermediate components may includehardware and/or software-based components. Many mobile devices 122 mayconnect with the network 127.

The network 127 may include wired networks, wireless networks, orcombinations thereof. The wireless network may be a cellular telephonenetwork, an 802.11, 802.16, 802.20, or WiMax network. Further, thenetwork 127 may be a public network, such as the Internet, a privatenetwork, such as an intranet, or combinations thereof, and may utilize avariety of networking protocols now available or later developedincluding, but not limited to TCP/IP based networking protocols.

The term “computer-readable medium” includes a single medium or multiplemedia, such as a centralized or distributed database, and/or associatedcaches and servers that store one or more sets of instructions. The term“computer-readable medium” shall also include any medium that is capableof storing, encoding or carrying a set of instructions for execution bya processor or that cause a computer system to perform any one or moreof the methods or operations disclosed herein.

In a particular non-limiting, exemplary embodiment, thecomputer-readable medium can include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium can be arandom access memory or other volatile re-writable memory. Additionally,the computer-readable medium can include a magneto-optical or opticalmedium, such as a disk or tapes or other storage device to capturecarrier wave signals such as a signal communicated over a transmissionmedium. A digital file attachment to an e-mail or other self-containedinformation archive or set of archives may be considered a distributionmedium that is a tangible storage medium. Accordingly, the disclosure isconsidered to include any one or more of a computer-readable medium or adistribution medium and other equivalents and successor media, in whichdata or instructions may be stored. These examples may be collectivelyreferred to as a non-transitory computer readable medium.

In an alternative embodiment, dedicated hardware implementations, suchas application specific integrated circuits, programmable logic arraysand other hardware devices, can be constructed to implement one or moreof the methods described herein. Applications that may include theapparatus and systems of various embodiments can broadly include avariety of electronic and computer systems. One or more embodimentsdescribed herein may implement functions using two or more specificinterconnected hardware modules or devices with related control and datasignals that can be communicated between and through the modules, or asportions of an application-specific integrated circuit. Accordingly, thepresent system encompasses software, firmware, and hardwareimplementations.

In accordance with various embodiments of the present disclosure, themethods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedembodiment, implementations can include distributed processing,component/object distributed processing, and parallel processing.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionality as describedherein.

Although the present specification describes components and functionsthat may be implemented in particular embodiments with reference toparticular standards and protocols, the invention is not limited to suchstandards and protocols. For example, standards for Internet and otherpacket switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP,HTTPS) represent examples of the state of the art. Such standards areperiodically superseded by faster or more efficient equivalents havingessentially the same functions. Accordingly, replacement standards andprotocols having the same or similar functions as those disclosed hereinare considered equivalents thereof.

A computer program (also known as a program, software, softwareapplication, script, or code) can be written in any form of programminglanguage, including compiled or interpreted languages, and it can bedeployed in any form, including as a standalone program or as a module,component, subroutine, or other unit suitable for use in a computingenvironment. A computer program does not necessarily correspond to afile in a file system. A program can be stored in a portion of a filethat holds other programs or data (e.g., one or more scripts stored in amarkup language document), in a single file dedicated to the program inquestion, or in multiple coordinated files (e.g., files that store oneor more modules, sub programs, or portions of code). A computer programcan be deployed to be executed on one computer or on multiple computersthat are located at one site or distributed across multiple sites andinterconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

As used in this application, the term ‘circuitry’ or ‘circuit’ refers toall of the following: (a) hardware-only circuit implementations (such asimplementations in only analog and/or digital circuitry) and (b) tocombinations of circuits and software (and/or firmware), such as (asapplicable): (i) to a combination of processor(s) or (ii) to portions ofprocessor(s)/software (including digital signal processor(s)), software,and memory(ies) that work together to cause an apparatus, such as amobile phone or server, to perform various functions) and (c) tocircuits, such as a microprocessor(s) or a portion of amicroprocessor(s), that require software or firmware for operation, evenif the software or firmware is not physically present.

This definition of ‘circuitry’ applies to all uses of this term in thisapplication, including in any claims. As a further example, as used inthis application, the term “circuitry” would also cover animplementation of merely a processor (or multiple processors) or portionof a processor and its (or their) accompanying software and/or firmware.The term “circuitry” would also cover, for example and if applicable tothe particular claim element, a baseband integrated circuit orapplications processor integrated circuit for a mobile phone or asimilar integrated circuit in server, a cellular network device, orother network device.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andanyone or more processors of any kind of digital computer. Generally, aprocessor receives instructions and data from a read only memory or arandom access memory or both. The essential elements of a computer are aprocessor for performing instructions and one or more memory devices forstoring instructions and data. Generally, a computer also includes, oris operatively coupled to receive data from or transfer data to, orboth, one or more mass storage devices for storing data, e.g., magnetic,magneto optical disks, or optical disks. However, a computer need nothave such devices. Moreover, a computer can be embedded in anotherdevice, e.g., a mobile telephone, a personal digital assistant (PDA), amobile audio player, a Global Positioning System (GPS) receiver, to namejust a few. Computer readable media suitable for storing computerprogram instructions and data include all forms of non-volatile memory,media and memory devices, including by way of example semiconductormemory devices, e.g., EPROM, EEPROM, and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a devicehaving a display, e.g., a CRT (cathode ray tube) or LCD (liquid crystaldisplay) monitor, or projector, for displaying information to the userand a keyboard and a pointing device, e.g., a mouse or a trackball, bywhich the user can provide input to the computer. Other kinds of devicescan be used to provide for interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, e.g.,visual feedback, auditory feedback, or tactile feedback; and input fromthe user can be received in any form, including acoustic, speech, ortactile input.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back end component,e.g., as a data server, or that includes a middleware component, e.g.,an application server, or that includes a front end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back end, middleware, or front end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent to those of skill in the art upon reviewingthe disclosure. Other embodiments may be utilized and derived from thedisclosure, such that structural and logical substitutions and changesmay be made without departing from the scope of the disclosure.Additionally, the illustrations are merely representational and may notbe drawn to scale. Certain proportions within the illustrations may beexaggerated, while other proportions may be minimized. Accordingly, thedisclosure and the figures are to be regarded as illustrative ratherthan restrictive.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context of separate embodiments can also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment canalso be implemented in multiple embodiments separately or in anysuitable sub-combination. Moreover, although features may be describedabove as acting in certain combinations and even initially claimed assuch, one or more features from a claimed combination can in some casesbe excised from the combination, and the claimed combination may bedirected to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings and describedherein in a particular order, this should not be understood as requiringthat such operations be performed in the particular order shown or insequential order, or that all illustrated operations be performed, toachieve desirable results. In certain circumstances, multitasking andparallel processing may be advantageous. Moreover, the separation ofvarious system components in the embodiments described above should notbe understood as requiring such separation in all embodiments, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

One or more embodiments of the disclosure may be referred to herein,individually and/or collectively, by the term “invention” merely forconvenience and without intending to voluntarily limit the scope of thisapplication to any particular invention or inventive concept. Moreover,although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the description.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b) and is submitted with the understanding that it will not be usedto interpret or limit the scope or meaning of the claims. In addition,in the foregoing Detailed Description, various features may be groupedtogether or described in a single embodiment for the purpose ofstreamlining the disclosure. This disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter may be directed toless than all of the features of any of the disclosed embodiments. Thus,the following claims are incorporated into the Detailed Description,with each claim standing on its own as defining separately claimedsubject matter.

It is intended that the foregoing detailed description be regarded asillustrative rather than limiting and that it is understood that thefollowing claims including all equivalents are intended to define thescope of the invention. The claims should not be read as limited to thedescribed order or elements unless stated to that effect. Therefore, allembodiments that come within the scope and spirit of the followingclaims and equivalents thereto are claimed as the invention.

We claim:
 1. A method for constructing a componentized junction model using a lookup table, the method comprising: calculating, from map data, a route through a physical road junction; selecting, from a lookup table, one of a plurality of road junction templates for the route through the physical road junction, each road junction template specifying a different set of short road segment components, wherein the selected road junction template is a closest fitting road junction configuration to the physical road junction; generating a model of the physical road junction by assembling the set of short road segment components specified for the selected road junction template in the lookup table; and rendering the model of the physical road junction for display to a user.
 2. The method of claim 1, wherein the lookup table is associated with the map data and identifies each of the plurality of road junction templates for modeling physical road junctions stored in the map data.
 3. The method of claim 1, wherein a fidelity of the generated model of the physical road junction is increased or decreased by varying the number and type of road segment components specified in the plurality of road junction templates.
 4. The method of claim 1, wherein generating the model comprises: assembling the set of short road segment components in a specific order stored in the lookup table.
 5. The method of claim 4, wherein the specific order is stored in a syntax for the plurality of road junction templates.
 6. The method of claim 1, wherein the selected one of the plurality of road junction templates is a single decision point comprising an originating link component, a decision point component, and at least one destination link component.
 7. The method of claim 1, wherein the selected one of the plurality of road junction templates is a multiple decision point comprising an originating link component, decision point components, an intermediate link component, and at least one destination link component.
 8. The method of claim 1, wherein the generated model of the road junction is a three-dimensional model.
 9. The method of claim 1, further comprising: displaying the rendered model of the road junction.
 10. The method of claim 1, wherein the rendered model of the road junction is a static two-dimensional rendering or an animated three-dimensional rendering.
 11. A method for constructing a componentized junction model, the method comprising: calculating, by a navigation system, a route through a physical road junction; selecting, by the navigation system, one of a plurality of road junction templates for the route through the physical road junction, each of the plurality of road junction templates comprising a predefined syntax identifying a different set of predefined road segment components, each predefined road segment component representing a short road segment interconnectable with at least one other road segment component; modeling, by the navigation system, the physical road junction based on the predefined syntax of the selected one of the plurality of road junction templates; rendering, by the navigation system, the three-dimensional model of the physical road junction, and providing, by the navigation system, navigation instructions through the physical road junction with the rendered three-dimensional model of the physical road junction.
 12. The method of claim 11, wherein calculating the route comprises: applying junction inclusion rules to identify the physical road junction to be associated with the one of the plurality of road junction templates.
 13. The method of claim 11, wherein the predefined syntax identifies the selected template as a single decision point junction.
 14. The method of claim 13, wherein the predefined syntax comprises lane count and lane connectivity for an originating link component, a decision point component and at least one destination link component of the single decision point junction.
 15. The method of claim 11, wherein the predefined syntax identifies the selected template as a multiple decision point junction.
 16. The method of claim 15, wherein the predefined syntax comprises lane count and lane connectivity for originating link component, decision point components, an intermediate link component, and destination link components of the multiple decision point junction.
 17. The method of claim 11, wherein the predefined road segment components comprise an overpass road segment component or an underpass road segment component.
 18. A navigation system for constructing a componentized junction model: a memory configured to store map data and a plurality of road junction templates in a lookup table; a processor configured to: calculate, from the map data, a route through a physical road junction; select, from the lookup table, the closest fitting one of the plurality of road junction templates for the route through the physical road junction; model of the physical road junction by assembling a set of road segment components specified by the lookup table for the selected road junction template; and render the model of the physical road junction; and a display configured to display navigation instructions through the physical road junction with the rendered three-dimensional model of the physical road junction.
 19. The navigation system of claim 18, wherein the plurality of road junction templates are coded in the lookup table with a syntax identifying the type of road junction.
 20. The navigation system of claim 19, wherein the syntax identifies a specific order of road segment components for modeling the physical road junction. 